Testing word-breaking:

Also your commit subject is a bit long :) Suggestion:

template: Add break_words option to fill function

Note that these template functions can be used in many commands, not just jj log.

Generally, please do not use booleans as a parameters. This is the Boolean Blindness anti-pattern.
Use a constant instead, e.g. (feel free to bikeshed the case and name)

fill(80, self.description(), BREAK_LONG_LINES)
fill(80, self.description(), break.LONG_LINES) -- if there is something like a namespace

This makes the template more descriptive and the effect/intent is obvious to a reader. It also avoids confusion if there is more than one boolean argument: fill(..., true, false) was the first boolean breaking long lines or right-justify?

As a bonus it is more flexible for future changes, e.g. add more "modes" like justifying, breaking with a dash "-", ...

Use a constant instead, e.g. (feel free to bikeshed the case and name)

There neither are constants or enums in the template language, so this will be hard.

Generally, please do not use booleans as a parameters. This is the Boolean Blindness anti-pattern.

IIUC, the code looks for a named parameter here, so break_words=true should work. Could ask the author to add a test proving this, but I don't think this is a huge issue here. Generally I'd agree about booleans being not ideal, but the alternative in this templating DSL is probably to have another function fill_break_words, and I dislike that more (if we add more options later, we'll have to make a bunch of new functions to accommodate all possible options).

Use a constant instead, e.g. (feel free to bikeshed the case and name)

There neither are constants or enums in the template language, so this will be hard.

For completeness, this could be done, but I wouldn't recommend it:

[template-aliases]
FILL_BREAK_WORDS = 'true'

'format_commit(commit)' = '''
fill(50, commit.description(), FILL_BREAK_WORDS)
'''

Any user could come by and override their own template-aliases.FILL_BREAK_WORDS to equal 'false' (or even whatever else they want), so it's not a true constant.

You could also:

[template-config]
# This table doesn't exist in the schema, but you can define whatever you want
# in your config; jj does not error in this case (yet).
fill_break_words = true

[template-aliases]
'format_commit(commit)' = '''
fill(50, commit.description(), config("template-config.fill_break_words").as_boolean())
'''

But this moves function arguments into a config, which sounds weird. FWIW I do use this pattern in some of my template aliases for "default function arguments", but I don't think it makes sense for the upstream project to ship with this pattern.

Generally, please do not use booleans as a parameters.

For public Rust functions, I agree.

Maybe we can add a separate step for splitting long words? We can also add a dedicated template function for this step (instead of extending fill()), but I have no strong preference.

Generally, please do not use booleans as a parameters.

For public Rust functions, I agree.

Maybe we can add a separate step for splitting long words? We can also add a dedicated template function for this step (instead of extending fill()), but I have no strong preference.

Adding new functions for each variation in functionality can spiral into a bloated function list quickly.

Added a test for a template that uses the named param break_words=true